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Abstract — We  present  the  transport  unaware  link  improvement  proto¬ 
col  (TULIP),  which  dramatically  improves  the  performance  of  TCP  over 
lossy  wireless  links,  without  competing  with  or  modifying  the  transport-  or 
network-layer  protocols.  TULIP  is  tailored  for  the  half-duplex  radio  links 
available  with  today’s  commercial  radios  and  provides  a  MAC  acceleration 
feature  applicable  to  collision-avoidance  MAC  protocols  ( e.g IEEE  802.11) 
to  improve  throughput.  TULIP'S  timers  rely  on  a  maximum  propagation 
delay  over  the  link,  rather  than  performing  a  round-trip  time  estimate  of 
the  channel  delay.  The  protocol  does  not  require  a  base  station  and  keeps 
no  TCP  state.  TULIP  is  exceptionally  robust  when  bit  error  rates  are  high; 
it  maintains  high  goodput,  i.e.,  only  those  packets  which  are  in  fact  dropped 
on  the  wireless  link  are  retransmitted  and  then  only  when  necessary.  The 
performance  of  TULIP  is  compared  against  the  performance  of  the  Snoop 
protocol  (a  TCP-aware  approach)  and  TCP  without  link-level  retransmis¬ 
sion  support.  The  results  of  simulation  experiments  using  the  actual  code 
of  the  Snoop  protocol  show  that  TULIP  achieves  higher  throughput,  lower 
packet  delay,  and  smaller  delay  variance. 

I.  INTRODUCTION 

With  the  need  to  support  end-to-end  communication  services 
to  mobile  hosts,  wireless  networks  are  quickly  becoming  an  in¬ 
tegral  part  of  the  Internet  and  reliable  protocols  such  as  TCP  [21] 
must  be  supported  over  these  networks.  Mobile  users  requiring 
remote  access  to  corporate  LANs,  file  access  and  Web  transfers 
over  wireless  links  must  rely  upon  TCP  to  support  their  transac¬ 
tions.  Unfortunately,  although  TCP  works  very  well  for  wired 
networks  with  minimal  losses  other  than  those  due  to  conges¬ 
tion,  wired  and  wireless  networks  are  significantly  different  in 
terms  of  bandwidth,  speed,  propagation  delay,  and  channel  reli¬ 
ability.  In  particular,  wireless  channels  suffer  from  bursty  error 
losses  that  reduce  TCP’s  throughput,  because  TCP  incorrectly 
interprets  packet  loss  as  a  sign  of  congestion  that  forces  TCP 
to  back  off  from  further  transmission  and  reduce  its  congestion 
window.  As  a  result,  the  overall  throughput  of  the  connection  is 
drastically  reduced.  Methods  to  hide  these  losses  from  TCP  is 
an  active  area  of  research  [3]  [4]  [6]  [16]  [8]  [9]. 

Maximum  throughput  occurs  in  a  TCP  connection  when  the 
TCP  congestion  window  is  as  large  as  the  bandwidth-delay 
product  of  the  connection.  Current  versions  of  TCP  react  to 
losses  differently  and  adjust  the  TCP  congestion  window  in  var- 

°This  work  was  supported  in  part  by  the  Defense  Advanced  Research  Projects 
Agency  (DARPA)  under  Grants  DAAB07-95-D157  and  DAAH04-96-1-0210 


ious  ways.  Wireless  channels  present  an  additional  challenge 
in  that  losses  do  not  generally  occur  in  isolation,  i.e.,  wireless 
channels  are  often  characterized  by  periods  of  fading  in  which 
several  losses  occur  in  succession.  All  versions  of  TCP  are  un¬ 
able  to  gracefully  recover  from  this  situation  and  must  resort  to 
a  timeout  whenever  more  than  one  loss  occurs  per  window  of 
outstanding  data.  This  becomes  the  predominant  shortcoming 
of  TCP  over  wireless  links:  the  connection  suffers  long  idle  pe¬ 
riods  in  which  the  sender  is  idle  waiting  for  a  timeout,  and  when 
the  packet  is  finally  retransmitted  and  recovered,  the  congestion 
window  is  reduced  to  one  segment,  thereby  reducing  throughput 
until  the  congestion  window  again  grows  to  its  optimal  size. 

II.  Related  Work 

The  quest  to  solve  the  ills  of  TCP  over  lossy  wireless  links  is 
an  area  of  active  research.  Solutions  at  lower  protocol  levels  at¬ 
tempt  to  recover  losses  by  using  forward  error  correction(FEC) 
at  the  physical  layer.  FEC  is  generally  considered  to  be  a  lim¬ 
ited  approach  (although  it  remains  an  area  of  active  research) 
as  it  can  reverse  only  a  limited  number  of  bit  errors,  and  also 
is  costly  in  terms  of  packet  delay  due  to  computation  time  and 
power  consumption  in  an  environment  in  which  power  use  must 
be  minimized.  Solutions  based  on  higher-level  protocols  at¬ 
tempt  to  fool  TCP  by  hiding  the  lossiness  of  the  wireless  link 
and  fall  into  three  major  categories:  Link  Layer,  Split  Connec¬ 
tion,  and  Proxy. 

The  AIRMAIL  protocol  [3]  provides  a  reliable  link  layer 
in  conjunction  with  forward  error  correction(FEC).  In  this  ap¬ 
proach,  in  order  to  conserve  bandwidth  and  power  the  base  sta¬ 
tion  sends  an  entire  window  of  data  before  an  ACK  is  returned 
by  the  mobile  receiver.  Unfortunately,  a  consequence  of  this  ap¬ 
proach  is  that  there  is  no  opportunity  to  correct  errors  until  the 
end  of  an  entire  window,  which  can  cause  TCP  to  time  out  if  the 
error  rate  is  large  or  cause  a  large  variation  in  delay  depending 
upon  the  position  of  the  loss  in  the  window. 

DeSimone  et  al.  [2]  conclude  that  introducing  reliability  at 
the  link  layer  introduces  unnecessary  and  redundant  retransmis¬ 
sions,  because  of  competing  retransmission  strategies  between 
the  transport  and  link  layers.  However,  this  conclusion  was 
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reached  based  on  an  analysis  that  did  not  take  into  account  the 
very  generous  timeout  value  calculated  by  TCP  nor  its  granular¬ 
ity  of  500ms,  but  rather  an  ideal  case  in  which  a  timeout  occurs 
at  the  estimated  round-trip  time  value.  Balakrishnan  et  al.  [5] 
demonstrate  that  link-layer  protocols  that  fail  to  provide  in-order 
delivery  to  the  application  essentially  compete  with  the  upper 
layers  by  duplicating  retransmissions. 

In  the  split-connection  approaches,  the  TCP  connection  is 
split  between  the  source  and  base  station  and  then  between  the 
base  station  and  the  wireless  receiver  [4] [8],  I-TCP  [4]  runs  at 
the  base  station,  buffers  and  sends  ACKs  to  the  source  for  pack¬ 
ets  that  have  not  yet  been  acknowledged  by  the  receiver.  The 
drawback  to  this  approach  is  that  it  violates  the  semantics  of 
TCP,  and  cannot  therefore  be  easily  deployed  in  the  Internet. 
M-TCP  [8],  on  the  other  hand,  preserves  TCP  semantics  and 
aims  to  improve  throughput  for  connections  which  exhibit  long 
periods  of  disconnection.  M-TCP  is  not  a  complete  solution  and 
the  authors  state  the  algorithm  still  requires  a  good  link-layer 
protocol  to  recover  losses. 

In  the  proxy  approach,  a  proxy  is  inserted  between  sender  and 
receiver  TCP  hosts  to  help  TCP’s  performance.  A  well-known 
example  of  this  approach  is  the  Snoop  protocol  [6],  which  runs 
at  the  base  station;  Snoop  retransmits  lost  packets  and  sup¬ 
presses  duplicate  TCP  ACKs  by  sniffing  all  packets  entering  an 
interface  before  they  are  passed  on  to  IP.  Retransmissions  are 
performed  when  it  detects  two  duplicate  ACKs  for  any  packet 
it  has  seen  previously  and  stored  in  its  buffer.  Snoop  has  been 
shown  to  improve  TCP  performance  over  wireless  links  with  bit¬ 
error  rates  up  to  15  bits  per  millions  [6],  Snoop  must  maintain 
state  for  all  TCP  sessions  going  through  it. 

It  has  also  been  suggested  that  TCP-SACK  [11]  can  be  used  to 
improve  TCP  performance  over  wireless  links  [5].  TCP-SACK 
provides  for  end-to-end  selective  acknowledgment  (SACKs)  of 
received  TCP  segments.  TCP-SACK  would  certainly  expedite 
the  discovery  of  lost  packets  on  wireless  segments  if  no  underly¬ 
ing  link-level  recovery  were  used;  however,  the  algorithm  would 
still  incorrectly  interpret  lost  segments  on  the  wireless  link  as  a 
sign  of  congestion. 

III.  Protocol  Overview 

In  this  paper,  we  present  the  transport  unaware  link  improve¬ 
ment  protocol  (TULIP),  and  show  by  simulation  studies  (for  a 
more  detailed  protocol  description  and  extensive  simulation  re¬ 
sults  see  [10])  that  TULIP  allows  TCP  to  operate  efficiently  over 
wireless  networks,  with  no  changes  to  the  hosts  and  TCP’s  se¬ 
mantics,  and  without  requiring  proxies  between  sender  and  re¬ 
ceiver  TCP.  TULIP  is  service-aware  in  that  it  provides  reliability 
for  only  those  packets  (frames)  that  require  such  service,  but  it  is 
not  protocol-aware,  i.e.,  it  does  not  know  any  details  of  the  par¬ 
ticular  protocol  to  which  it  provides  its  reliable  service.  More 
specifically,  TULIP  provides  reliable  service  for  packets  car¬ 
rying  TCP  data  traffic,  and  unreliable  service  for  other  packet 
types,  such  as  UDP  traffic  (e.g.,  routing  table  updates  and  DNS 
packets)  and  TCP  acknowledgments  (ACKs).  TULIP  doesn't 


provide  reliable  service  to  TCP  ACKs  because  subsequent  cu¬ 
mulative  ACKs  supersede  the  information  in  the  lost  ACK.  The 
receiver  buffers  packets  and  passes  them  up  to  the  next  layer  in 
order,  thereby  preventing  TCP  from  generating  duplicate  ACKs 
in  the  event  that  a  packet  is  missing  from  the  expected  sequen¬ 
tial  packet  stream.  This  approach  eliminates  the  need  for  a 
transport-level  proxy  [6],  which  must  keep  per-session  state  to 
actively  monitor  the  TCP  packets  and  suppress  any  duplicate 
ACKs  it  encounters.  An  important  feature  of  TULIP  is  its  abil¬ 
ity  to  maintain  local  recovery  of  all  lost  packets  at  the  wireless 
link  in  order  to  prevent  the  unnecessary  and  delayed  retransmis¬ 
sion  of  packets  over  the  entire  path  and  a  subsequent  reduction 
in  TCP’s  congestion  window.  Flow  control  across  the  link  is 
maintained  by  a  sliding  window,  and  automatic  retransmission 
of  lost  packets  is  accomplished  by  the  sending  side’s  link  layer. 
Lost  packets  are  detected  at  the  sender  via  a  bit  vector  returned 
by  the  receiver  as  a  part  of  every  ACK  packet.  This  allows  for 
quick  and  efficient  recovery  of  packets  over  the  link  and  helps 
to  keep  delay  and  delay  variance  low.  However,  TULIP  is  de¬ 
signed  for  efficient  operation  over  the  half-duplex  radio  channels 
available  in  today’s  commercial  radios  by  strobing  packets  onto 
the  link  in  a  turn-taking  manner.  We  introduce  a  new  feature, 
MAC  Acceleration,  in  which  TULIP  interacts  with  the  MAC 
protocol  to  accelerate  the  return  of  link-layer  ACKs  (which  are 
most  often  piggybacked  with  returning  TCP  ACKs)  without  re¬ 
negotiating  access  to  the  channel.  TULIP  causes  no  modifica¬ 
tion  of  the  network  or  transport  layer  software,  and  the  link  layer 
is  not  required  to  know  any  details  regarding  TCP  or  the  algo¬ 
rithms  it  uses.  TULIP  maintains  no  TCP  state  whatsoever,  and 
makes  no  decisions  on  a  TCP-session  basis,  but  rather  solely  on 
a  per-destination  basis.  This  approach  greatly  reduces  the  over¬ 
head  of  maintaining  state  information  when  multiple  TCP  ses¬ 
sions  are  active  for  a  given  destination  (as  is  common  with  Web 
traffic).  From  the  transport  layer’s  point  of  view,  the  path  to  the 
destination  through  a  lossy  wireless  link  simply  appears  to  be  a 
slow  link  without  losses  and  TCP  simply  adjusts  accordingly. 

IV.  Implementation 

We  have  implemented  TULIP  and  Snoop  [6]  in  the  C++  Pro¬ 
tocol  Toolkit  (CPT)  [7] 1 .  A  key  feature  of  our  simulation  is  that 
it  is  based  on  the  exact  same  source  code  that  runs  in  the  WING 
prototypes  (which  are  wireless  IP  routers)  [15],  and  in  hosts  at¬ 
tached  to  the  WINGs.  The  IEEE  802.11  specifications  are  used 
at  the  physical  layer  to  emulate  the  broadcast  medium.  CPT  sim¬ 
ulates  the  wireless  and  wired  transmission  media  with  specific 
parameters  and  channel  characteristics  specified  through  script 
files  read  at  runtime.  Our  implementation  of  TULIP  runs  on  top 
of  FAMA-NCS  [13].  TULIP  in  turn  interacts  with  IP  [20]  and 
the  wireless  Internet  routing  protocol  (WIRP)  [19]  for  packet 
forwarding.  The  code  of  the  Snoop  protocol  [6]  was  modified 
from  the  on-line  FreeBSD  implementation2  to  run  in  CPT. 

1  We  thank  Rooftop  Communications  Corporation  for  donating  the  toolkit. 

2  We  thank  H. Balakrishnan  for  providing  on-line  source  code  at 
ftp://daedalus.cs.berkeley.edu/pub/snoop/ 
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V.  Performance 

TCP’s  performance  over  wireless  links  is  analyzed  through 
simulation  for  networks  subject  to  low  and  high  bit-error  rates, 
burst  losses,  and  fading.  We  evaluate  TCP’s  performance  un¬ 
der  three  different  situations:  when  there  are  no  underlying  link 
layer  retransmissions,  when  the  Snoop  protocol  [6]  is  used  at 
the  base  station,  and  when  TULIP  is  used.  The  simulation  ex¬ 
periments  assume  a  simple  configuration,  shown  in  Figure  1, 
with  a  base  station  and  a  single  wireless  host  connected  to  the 
base  station.  We  compare  TULlP’s  performance  to  the  perfor¬ 
mance  of  the  Snoop  protocol,  for  which  very  good  performance- 
improvement  results  have  been  reported  in  the  base  station  con¬ 
figuration. 

The  following  parameters  are  fixed  for  all  experiments:  the 
channel  capacity  from  the  wired  source  to  the  base  station  is 
10Mbps,  the  wireless  transmission  rate  is  1Mbps,  file  transfers 
are  lOMbytes  with  1400  byte  data  packets,  TULIP's  window 
size  is  8  packets,  and  the  offered  traffic  is  a  Poisson  source  with 
an  average  rate  of  1Mbps.  These  specifications  are  the  same 
as  those  used  in  the  Snoop  experiments  [6],  except  for  the  ra¬ 
dio  characteristics  (including  a  lower  transmission  rate  for  our 
experiments). 


Exponential  Loss  or  Fading 


Fig.  1 .  Topology  for  Experiments. 


A.  Low  Error  Rates 

Figure  2(a)  shows  the  average  throughput  for  three  cases: 
TCP  with  no  underlying  link-layer  retransmissions  (labeled  no 
LL),  TCP  with  the  Snoop  protocol  and  with  TULIP.  Bit  error 
rates  are  varied  from  0  to  15  bits/million  and  the  receiver  win¬ 
dow  size  is  42Kbytes.  When  the  link  errors  are  zero  the  graphs 
show  that  MAC  Acceleration  provides  a  4  -  5%  improvement 
in  throughput.  For  error  rates  under  0.5  bits/million,  TCP  is 
able  to  keep  up  with  the  losses  and  does  not  show  apprecia¬ 
ble  performance  degradation.  However,  as  losses  begin  to  rise, 
it  is  apparent  that  traditional  TCP  can  no  longer  keep  up  with 
the  losses  and  the  throughput  degrades  considerably.  Both  the 
Snoop  protocol  and  TULIP  show  decreased  throughput  as  the 
BER  rises;  however,  their  overall  throughput  is  consistently  bet¬ 
ter  than  unassisted  TCP.  The  reduction  in  throughput  is  due  to 
the  numerous  retransmissions  that  occur  as  error  rates  increase. 

Figure  2(b)  shows  the  average  packet  delay  with  TULIP  is 
lower  than  the  Snoop  protocol  in  every  instance,  and  as  the  error 
rates  increase,  TULlP’s  standard  deviation  is  also  lower  than  the 
Snoop  protocol.  TULlP’s  delay  is  smaller  because  TULIP  has 
a  faster  retransmission  mechanism.  This  becomes  apparent  as 
the  error  rate  increases  and  Snoop's  variance  jumps  up  at  a  BER 
of  15  bits  per  million  when  it  has  trouble  with  scattered  losses 
within  a  window  and  with  the  occasional  loss  of  retransmitted 


packets.  The  end-to-end  delay  in  this  figure  is  reduced  by  more 
than  half  over  a  session  with  a  42K  receiver  window  because  the 
queueing  at  the  base  station  is  reduced  substantially.  This  leads 
to  our  recommendation  that  mobile  nodes  should,  in  general, 
advertise  a  smaller  window  size  to  reduce  delay  and  lessen  the 
possibility  of  congestion  at  the  base  station. 

B.  High  Error  Rates 

Some  public  wireless  communication  providers  [14]  [18]  re¬ 
port  typical  wireless  one-hop  packet  loss  rates  between  10  - 
40%.  Lor  this  reason,  we  increase  the  bit  error  rates  on  the 
channel  to  very  high  values,  i.e.,  from  15  to  75  bits  per  million 
(corresponding  to  packet  loss  rates  from  16  to  85%). 

TCP’s  throughput  is  shown  in  Ligure  3(a)  for  a  16Kbyte  re¬ 
ceiver  window.  The  graph  clearly  shows  that,  as  the  bit  er¬ 
ror  rate  increases,  all  three  protocols  show  a  reduced  turn  in 
throughput.  With  a  BER  of  15  bits/million  the  TCP  connec¬ 
tion  with  no  link-layer  retransmissions  (labeled  no  LL)  has  de¬ 
graded  significantly  and  comes  to  a  near  standstill  for  error  rates 
above  30  bits/million.  Beyond  a  BER  of  30  bits/million  Snoop’s 
throughput3  drops  off  quickly  and  diverges  from  TULlP’s 
throughput,  which  decreases  slowly  as  error  rates  increase. 
These  error  rates  are  characterized  by  many  multiple  losses  per 
window  of  data.  TULIP  can  easily  recover  from  these  episodes 
and  the  connection  simply  appears  increasingly  slower  to  the 
transport  layer. 

Ligure  3(b)  shows  the  average  end-to-end  packet  delay  and 
standard  deviation  for  the  corrected  Snoop  and  TULIP.  This  plot 
shows  that  the  delays  and  deviation  with  the  Snoop  protocol  are 
significantly  larger  than  with  TULIP  once  error  rates  exceed  35 
bits/million.  The  larger  delay  is  because  the  Snoop  protocol 
has  trouble  recovering  multiple  losses  per  window  and  also  rec¬ 
ognizing  when  retransmissions  are  also  lost.  Snoop  must  rely 
heavily  on  its  timer  and  cumulative  ACKs  for  retransmissions 
and  gets  stuck  trying  to  retransmit  the  first  packet  in  a  series  of 
losses.  The  deviation  is  high  here  because  losses  are  tackled  one 
by  one  and  in  order,  i.e.,  once  the  first  loss  is  recovered,  then  the 
next  is  tackled  and  so  on.  TULIP,  on  the  other  hand,  creates  a 
retransmission  list  upon  the  first  receipt  of  an  ACK  and  knows 
exactly  which  packets  are  missing  because  each  ACK  specifies 
the  complete  state  at  the  receiver’s  buffer.  In  addition,  if  retrans¬ 
mitted  packets  need  to  be  again  retransmitted,  TULIP  is  able 
to  do  this  as  soon  as  it  has  received  any  ACK.  The  deviation 
is  smaller  in  TULIP  because,  with  multiple  losses  per  window, 
it  is  often  the  case  that  errors  further  down  in  the  window  are 
recovered  before  the  first  error.  Therefore,  by  the  time  the  first 
error  is  recovered,  all  the  packets  can  be  released  to  the  higher 
layer  in  sequence. 

C.  Burst  Losses  and  Fading 

In  this  section  we  examine  TCP's  performance  in  the  pres¬ 
ence  of  packet  burst  losses  and  fading  on  the  wireless  link.  Lad- 

3Two  lines  are  shown  for  Snoop:  in  the  one  labeled  Snoop  w/fix  we  have  fixed 
a  coding  bug  in  the  on-line  source  release  code. 
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ing  causes  periods  of  silence  on  the  channel,  during  which  time 
neither  sender  nor  receiver  can  hear  each  other.  Fading  is  of¬ 
ten  caused  by  the  movement  of  mobile  nodes,  but  can  also  be 
caused  by  objects  which  move  in  front  of  and  around  a  mobile 
node. 

C.  1  Uniform  Distribution  of  Burst  Losses 

In  the  method  used  by  Balakrishnan  et.  al.  [5],  burst  losses  of 
a  specific  size  are  distributed  uniformly  over  the  run  of  the  ex¬ 
periment.  The  results  when  bursts  of  sizes  2,4  and  6  data  packets 
are  spread  every  64Kbytes  of  data  are  shown  in  Table  I.  Be¬ 
cause  of  FAMA’s  handshake,  the  sender  would  not  send  more 
than  one  packet  into  the  channel  during  a  fading  period,  because 
it  would  not  receive  the  necessary  CTS  to  send  any  more  data 
packets.  The  same  would  the  case  for  DWFMAC  [1],  However, 
this  experiment  is  still  interesting  to  show,  because  it  indicates 
that  TULIP  provides  smaller  delays  and  slightly  better  through¬ 
put  than  Snoop,  even  in  such  rare  cases  in  which  the  MAC  layer 
manages  to  send  multiple  packets  into  the  channel  that  reach  the 
receiver  in  error,  even  though  the  corresponding  RTS  and  CTS 
packets  did  not. 

C.2  Markov  Model  of  Fading 

The  method  to  simulate  channel  fading  consists  of  a  two- 
state  Markov  model  taken  directly  from  the  work  by  Lettieri 
el  a/.  [17],  which  is  also  discussed  by  Wang  el  al.  [22]  and 
S warts  el  al.  [12].  Briefly,  the  model  consists  of  a  two-state 
Markov  chain  representing  Good  and  Bad  states  on  the  channel, 
transition  probabilities  into  and  out  of  the  states,  and  error  loss 
probabilities  associated  with  each  state.  We  have  performed  this 
experiment  for  a  pedestrian  speed  of  2km/hr  and  the  results  are 
presented  in  Figures  4(a)  and  (b)  as  the  BER  in  the  Good  state 
is  varied  from  0.01  to  100  bits/million  and  the  loss  probability 


in  the  Bad  state  held  constant  at  50%.  Figure  4(a)  shows  that 
TULIP  and  the  Snoop  protocol  display  similar  performance  as 
long  as  the  error  rates  are  low;  however.  Snoop’s  throughput  be¬ 
gins  to  diverge  and  fall  below  TULIP  once  error  rates  exceed  10 
bits/million.  The  performance  of  TCP  with  no  underlying  re¬ 
transmissions  degrades  once  error  rates  exceed  0. 1  bits/million, 
or  approximately  l/8Mbytes.  The  end-to-end  packet  delay,  de¬ 
picted  in  Figure  4(b),  shows  that  the  average  delay  for  TULIP 
and  the  Snoop  protocol  are  similar;  however,  the  standard  de¬ 
viation  for  Snoop  is  again  higher.  For  the  highest  error  rate 
shown,  100  bits/million,  TULIP  provides  a  much  lower  delay 
and  a  tighter  bound  on  the  deviation. 

VI.  Conclusion 

The  results  of  our  simulations  show  that  TULIP  performs  bet¬ 
ter  for  any  bit-error  rate  than  Snoop  and  TCP  with  no  underlying 
retransmissions.  In  addition,  at  very  high  error  levels,  TULIP’s 
throughput  is  up  to  three  times  higher  than  both  Snoop  and  TCP 
with  no  underlying  retransmissions.  End-to-end  delay  becomes 
a  problem  as  the  losses  on  the  link  increase;  however,  reduc¬ 
ing  the  size  of  the  receiver’s  advertised  window  can  help  to 
alleviate  the  queuing  delay.  The  end-to-end  packet  delay  with 
TULIP  is  significantly  lower  than  the  other  two  approaches  and, 
in  contrast  to  Snoop,  the  standard  deviation  of  delay  with  TULIP 
grows  only  slightly  with  increasing  error  rates.  We  have  exam¬ 
ined  the  effects  of  burst  losses  and  channel  fading  and  our  re¬ 
sults  show  that  again  the  TULIP  approach  quickly  retransmits 
the  dropped  packets  once  the  channel  is  active  again,  yielding 
reduced  but  consistent  throughput.  The  simulations  show  that 
during  fading  TULIP  provides  higher  throughput  and  lower  end- 
to-end  delays  compared  to  both  Snoop  and  TCP  with  no  under¬ 
lying  retransmissions. 

The  advantage  of  our  approach  over  other  published  ap- 
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j  Bursts  Distributed  every  64Kbytes  f 

Burst  Size 
#packets 

TULIP 

Throughput(Kbps) 

Snoop 

Throughput(Kbps) 

A 

(Kbps) 

TULIP 

Delay  d=  dev. (ms) 

Snoop 

Delay  d=  dev.  (ms) 

2 

587.3 

562.6 

24.7 

540±56 

582±60 

4 

550.0 

527.6 

22.4 

579±74 

621±84 

6 

516.1 

496.4 

19.7 

618±98 

660±114 

TABLE  I 

Throughput  of  TULIP  and  Snoop  in  the  presence  of  bursts  of  length  2,4  and  6  packets.  Burst  periods  are  distributed  every 

64KBYTES  OF  DATA.  RECEIVER  WINDOW  IS  42KBYTES. 
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Fig.  4.  TULIP  and  Snoop  during  Markov  Fading  Model.  Loss  probability  in  bad  state  is  50%  and  BER  in  good  state  is  varied.  Pedestrian  speed  2km/hr.  (a) 
Throughput  (b)  End-to-end  delay  and  standard  deviation 


proaches  is  that  we  keep  no  TCP  state  and  therefore  do  not  need 
to  look  into  the  TCP  packet  headers.  This  means  that  TULIP 
works  correctly  with  any  current  or  future  version  of  TCP  (e.g., 
TCP-SACK),  even  if  TCP  headers  are  encrypted.  TULIP  works 
with  both  IPv4  and  IPv6;  in  the  latter  case,  TCP  data  packets  can 
be  identified  as  requiring  reliable  service  from  the  NextHeader 
field  in  the  IPv6  header.  In  addition,  because  our  approach  does 
not  restrict  the  network  to  the  presence  of  a  base  station,  it  can 
easily  be  applied  to  multi-hop  wireless  networks.  Furthermore, 
by  controlling  the  MAC  layer,  TULIP  conserves  wireless  band¬ 
width  by  piggybacking  TCP  ACKs  with  link-layer  ACKs  and 
returning  them  immediately  across  the  channel  through  MAC 
Acceleration. 
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